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ABSTRACT 

This thesis develops and provides an accurate simulation mode] of the 
communications pathway between Fleet Numerical Meteorology Oceanographic Center 
(FNMOC) Monterey, California and Naval Atlantic Meteorology Oceanographic Center 
(NLMOC) Norfolk, Virginia. In order to fulfill its mission to provide global weather 
forecasts to the warfighter, FNMOC must provide timely data to its customers. This 
mode! provides an analytic approach toward determining time delay with respect to 
bandwidth and its management. Additionally, this model enables the user to analytically 
determine the effects of hardware changes. Although other customers exist besides 
NLMOC Norfolk, it is a major consumer of data files in support of weather forecasting. 
The other major links are located in Rota, Spain; San Diego, California; Yokosuka, 
Japan; and Peal Harbor, Hawaii. This model is, however, scalable to simulate these other 
major links. The target audience for this information model is the technical support 
personnel at FNMOC Monterey, California, who manage the link to NLMOC Norfolk, 
Virginia. The information that supports this model was derived from field visits to 
technical personnel at FNMOC Monterey. No other communications software model has 
been developed at the present time. The discrete event software simulation tool used for 


this model is Extend™. 
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THESIS DISCLAIMER 
The reader is cautioned that the computer programs developed in this research 
may not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and logic 
errors, they cannot be considered validated. Any application of these programs without 


additional verification is at the risk of the user. 
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EXECUTIVE SUMMARY 


Fleet Numerical Meteorology Oceanographic Center (FNMOC) Monterey, has as 
its primary mission to provide timely, global weather information to the warfighter. The 
major customers of this weather information are located in Rota, Spain; San Diego, 
California, Yokosuka, Japan; Pearl Harbor, Hawaii; and Norfolk, Virginia. Each 
customer is assigned its own region of the world to forecast and also obtains its own 
particular data via different paths and at different rates of data transfer. 

This thesis develops and provides an accurate simulation model of the 
communications pathway between Fleet Numerical Meteorology Oceanographic Center 
(FNMOC) Monterey, California and Naval Atlantic Meteorology Oceanographic Center 
(NLMOC) Norfolk, Virginia. NLMOC Norfolk was chosen because it is a major 
consumer of weather data. This model, however, is scalable to simulate these other 
major links for future study. 

To deliver weather data to NLMOC Norfolk, FNMOC Monterey has developed 
an architecture that ensures a timely response to data requests. There are typically two 
types of data transfers that take place every day to NLMOC Norfolk. The first type of 
data transfer is a relatively small update data file. Although requested with a 250 
kilobyte file it is typically answered with a smaller size data file of approximately 100 
kilobytes. This request and subsequent response occurs approximately every fifteen 
sists The second type of data transfer is extremely large and takes place every twelve 
hours, also upon request. This data file is produced once all weather observations are 


received by FNMOC Monterey and subsequently input into the weather forecasting 


AV 














model. This weather forecasting program produces a very large, one gigabyte file. This 
file is then sent the NLMOC Norfolk. 

All of these messages are sent along the same pathway using Ethernet technology. 
As a result of Ethernet protocol, every twelve hours no othe: messages may transfer until 
the very large database has been fully sent. These data are sent and received at the 
maximum rate of a T-1 line or 1.544 megabits per second (Mbps). Although this transfer 
rate 1s relatively fast, such immense data transfers cause a theoretical minimum system 
delay of approximately one hour and twenty-eight minutes. This system delay occurs 
every twelve hours. This data transfer rate and its associated delay are the focus of this 
thesis. 

The pathway used to transfer data is a commercially obtained leased line. It is 
therefore, always available to both FNMOC and NLMOC without Interruption or 
requests from other customers. Although the path between Monterey and Norfolk is 
exclusive, there still exist other limitations. The maximum data rate for this line is 
limited by the rate at which NLMOC Norfolk can receive data. NLMOC’s server allows 
data transfer rates as high as a T-1 line (1.544 Mbps), however this same server provides 
email and outbound data transfer services as well. This causes the true inbound rate from 
FNMOC Monterey to be limited to approximately 0.56 Mbps or 36 percent of maximum 
T-1 line speed. 

The model is used to develop and analyze three scenarios. The first demonstrates 
the transfer of typical data at the maximum theoretical T-1 line rate of 1.544 Mbps. Its 
subsequent time delay is found to equal one hour and twenty-eight minutes. 
Unfortunately NLMOC Norfolk routinely experiences data delays of four hours every 
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time the one gigabyte transfer occurs. Their using this same server for other purposes 
such as outbound customer traffic causes this further delay over the maximum theoretic 
time delay. This delay could however, be greatly decreased if NLMOC Norfolk 
purchased an additional server solely dedicated to receiving data from FNMOC 
Monterey. 

The second scenario determines typical time delays if the entire line bandwidth 
were increased to 10 megabits per second, which is the current rate at which FNMOC 
Monterey is able to transmit data. To achieve this, more bandwidth would have to be 
purchased by NLMOC Norfolk through expanding the current lease agreement. At 10 
megabits per second however, the time delay caused by a one gigabyte message would be 
decreased to 13.3 minutes. 

The third scenario demonstrates expected time delays if the one gigabyte data file 
were managed differently and therefore allowed to be transferred in parts once every 
hour, equally spread over the standard twelve hour time period. Using the T-1 line 
already in place, the time delay would be decreased to 7.2 minutes every hour of 
transmission. This change could be realized through a management alteration to the 
watbinded data. 

Each scenario invokes a monte-carlo algorithm to allow for actual, unforeseen 
message delays. Each message transfer time is sampled from a standard normal 
distribution using its particular mean time to send and a standard deviation of five 
seconds. 

The discrete event software simulation tool chosen for this model is Extend™, 
developed by Imagine That, Incorporated in San Jose, California. Originally fielded in 
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the early 1990’s, Extend™ provides the user with tools to develop a rigorous simulation 
on a desktop computer. It is fully programmable by the user without third party 
contributions. It does this by enabling the user to choose item generators, time delays, 
and queues in such a way that a tailored, numeric simulation can be accurately defined 
and run. 

This software model provides an analytic approach toward determining expected, 
theoretic time delays with respect to bandwidth and its management. Additionally, this 
model enables the user to analytically determine the effects of proposed, future hardware 
changes. 

The target audience for this simulation model is the technical Support personne] at 
FNMOC Monterey, California, who manage the link with NLMOC Norfolk, Virginia. 
The information that supports this model was derived from field visits to technical 
personnel at FNMOC, Monterey, California. 

At the time of this study, no other communications software model had been 


developed or considered by FNMOC Monterey. 
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I. INTRODUCTION 


A. BACKGROUND AND PURPOSE 


In today’s environment of constantly mn rates of data transfer and 
potentially lower costs through system improvements, the potential to upgrade a system 
is very high. Therefore, an analytic method to predetermine outcomes and demonstrate 
effects of potential hardware and software alterations must be developed and used 


regularly. 


One such method is a simulation model. This model must be capable of being 
scalable and alterable to conform well to current system parameters. It should also be 
capable of allowing the input of actual data as well as allow for random number 
generation in order to produce the most realistic outcomes. All of this is done so that 
important decisions concerning system improvements can be made wisely by those who 
employ it before embarking on the new change. 


1. FNMOC Monterey 


Fleet Numerical Meteorology and Oceanography Center (FNMOC) is located at 
the Naval Postgraduate School Annex on Airport Road, Monterey, California. It is 
supported by 267 individuals, of whom 95 are military and 172 are civilian. FNMOC 
provides around-the-clock operational oceanographic and meteorological support to the 
Department of Defense, U.S. Navy, other U.S. Government agencies, and elements of the 
armed forces of allied nations. It is a third-echelon command under the Chief of Naval 
Operations (CNO), Oceanographer of the Navy, located at the Naval Observatory in 


Washington, DC, and the Commander, Naval Meteorology and Oceanography Command 
] 

















(CNMOC), located at Stennis Space Center (SSC), Mississippi. FNMOC works with its 

four other third-echelon commands that include the other production data center at SSC, 

Naval Oceanographic Office (NAVO), Naval Ice Center (NAVICE), Suitland, Maryland, 

and three theater Meteorology and Oceanography (METOC) centers: Naval Pacific 

METOC Center (NPMOC West) at Pear] Harbor, Hawaii; Naval Atlantic METOC Center 

(NLMOC) at Norfolk, Virginia; and Naval European METOC Center (NEMOC) at Rota, 
| 

Spain. Figure 1 illustrates the chain of command. FNMOC also has two detachments 

(FNMOD's) that provide climatology support and weather communications coordination. 

These detachments, which are located in Asheville, North Carolina, and Tinker Air Force 

Base (AFB), Oklahoma, support the Navy and the Marine Corps, respectively. 


Cc 
Oceanographer of the Navy 
Naval Observatory. DC 


CNMOC 
Stennis Space Center, 
MS 

NP MOC NAVO FNMOC NLMOC NEMOC 
Pean Hamo: P41 Ssc, MS Monterey, CA Norfolk, VA Rota, SP 
NPMOC WEST NAVICE 

Couarn Surtland. MD 
FNMOD FNMOD 
Ashvitie, NC Tinker AFB, OK 


Figure 1. FNMOC Monterey Chain of Command (From Ref. 7) 








NLMOC’s primary customers are: 


e Northern European Meteorology and Oceanography Center (NEMOC) in 


Rota, Spain 

e Naval Atlantic Meteorology and Oceanography Center (NLMOC) in Norfolk, 
Virginia 

e Naval Pacific Meteorology and Oceanography Center (NPMOC) in San 


Diego, California 


e Naval Pacific Meteorology and Oceanography Center (NPMOC WEST) in 


Pearl Harbor, Hawaii 


e Naval Pacific Meteorology and Oceanography Center (NPMOC EAST) in 


Yokosuka, Japan 


This study will focus on the communication link between FNMOC Monterey and 
NLMOC Norfolk because of the large amount of data that is routinely requested by them. 

2. Extend™ Software 

The discrete event software simulation tool chosen for this model is Extend™ 
developed by Imagine That, Incorporated in San Jose, California. Originally available for 
customer use in the early 1990's, Extend™ provides the user with tools to develop a 
rigorous simulation on a desktop computer. It is fully programmable by the user without 
third party contributions. It does this by enabling the user to choose item generators, time 
delays, and queues in such a way that a tailored, numeric simulation model can be 


accurately defined and run. 














Extend™ uses a "drag-and-click" methodology through the use of a many 
different pre-defined "blocks." This type of Graphical User Interface (GUI) makes the 
building of models fast and accurate. Most of the "blocks" available for use within 
Extend™ are used in the model developed for this study; the others were user defined. 
They will each be explained in the model chapter of this thesis. These blocks can be 
opened to allow a user to code and thereby implement specific behaviors within that 
particular block. Many blocks can also be aggregated into one block by selecting the 
blocks desired and choosing the "make hierarchical" option. This helps to simplify a 
section of the model, especially when many blocks and their connections are present. 
The model developed in this study uses this option frequently. 

Blocks awaiting use are saved and maintained in separate "libraries." The user 
opens these libraries as necessary so that the block can be retrieved. Once the blocks are 
connected and attributes are assigned to each block the model is ready to run. More 
details concerning blocks and _ hierarchical design will be discussed in the model 
description chapter. 

Extend™ also provides user output in many forms. For example, a plotter block 
can be chosen that will automatically graph the desired output. This same output will be 
used to show the results of the model developed for this thesis. It also provides the 
numbers that make up the plot so that the user can perform further data analysis if 
necessary. Additionally Extend™ allows the user to select an animation option, which 
reveals item location during the simulation. Although it causes the simulation to run 


much slower it is most helpful in model debugging and demonstration. 








B. OBJECTIVE 


The objective of this thesis is to provide a simulation model of the eoanestion 
between NLMOC Norfolk and FNMOC Monterey. This model will allow modifications 
in order to evaluate the effects of proposed system changes. In particular this model will 
be able to run on a Pentium III’, 500 megahertz, desktop computer and produce usable 


output. 


C. RESEARCH TOPICS 


Research topics explored by this thesis are divided among three excursions. The 
first excursion will determine the current, minimum theoretic time delay of transferring a 
one gigabyte message to from FNMOC Monterey to NLMOC Norfolk using a standard 


T-1 line rate of 1.544 Mbps. 


The second excursion demonstrates the minimum theoretic time delay of 
transferring a one gigabyte message to from FNMOC Monterey to NLMOC Norfolk 
using an improved bit transfer rate of 10 Mbps. This excursion is extremely useful 
because NLMOC Monterey is current able to send data at that rate, but NUMOC Norfolk 
can only receive at 1.544 megabits per second. However, it can upgrade its line speed 


through expanding its leased line service agreement. 


The third excursion demonstrates the effects of parsing the one gigabyte message 
into twelve equal parts and allowing them to be sent once every hour. The line speed 


used in this case is 1.544 megabits per second, which is already in place. 
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Il. KFNMOC OPERATIONS 


A. DATA GATHERING 

FNMOC Monterey receives thousands of observations every day. These 
observations are input into a very robust program entitled the Naval Operational Global 
Atmospheric Prediction System (NOGAPS). It has the ability to compare current 
readings with previously held data and run an algorithm to determine the weather forecast 


for a particular region. 


B. DATA TRANSMISSION 


Once the data have been produced by POPS they are placed into geographically 
"gridded" binary files, referred to as “grib" files. These “grib" files are then sent and 
stored in an internal database, where they await further transfer once a customer’s request 


is received. 


Requests for data arrive from NLMOC Norfolk approximately every fifteen 
minutes. They are typically 250 kilobytes in size. These requests are answered using 


recently updated files which are relatively smaller, approximately 100 kilobytes in size. 


However, once every twelve hours, NLMOC Norfolk requests that the entire 
database be updated. Using a 250 kilobyte message, this request is made. It is then 
answered by sending a large, one gigabyte message containing the entire database. 


C. HARDWARE 


FNMOC Monterey operates three Cray’™ Supercomputers and two OASIS Sun™ 
Minicomputers in order to run and store its forecast programs and data. Combined with 


resident switches and routers, this information is received and transferred internally 
7 














within FNMOC Monterey at a "Fast Ethernet" speed of 10 Mbps. However, these data 
are sent externally from FNMOC Monterey at the maximum rate of a T-1 line or 1.544 
Mbps. The limiting factor is NLMOC Norfolk’s ability to receive data from FNMOC 
Monterey. NLMOC Norfolk is limited to T-1 line speed for both receiving and sending 
data. Therefore this model simulates the bandwidth of 1.544 as a starting point in the 


analysis. 











I. MODEL DESCRIPTION 


A. OVERVIEW 


The model developed for this study simulates an Ethernet operating at different 
bandwidths and thereby allows message traffic to be transferred at different rates. This 
model also determines expected, theoretic time delays of message traffic and Ethernet 
utilization with respect to bandwidth and its management. This analytical approach is 
especially useful when determining the effects of proposed system changes. The 
software Extend™ chosen for this model simulates well the individual parts of the 
sending and receiving nodes and the required Ethernet of the overall communication 
system. Extend™ refers to these individual parts as "blocks". 


1. Building "Blocks" 


Extend™ uses predefined scripts of computer code known as "blocks" and 
represents each of them with a highly descriptive icon. Each block has its own 
characteristics and is easily selected by the user when its library is opened. Blocks of a 
similar type are aggregated together into one library. Once opened, each library remains 
available for that particular model. This allows the model itself to be smaller in terms of 
required memory because the model itself simply references each block’s computer code 


resident in each library during the simulation run. 


Additionally double clicking on it will access each block. It will either display its 
“dialogue box" or if “hierarchical”, it will display the blocks that it contains. If a dialog 
box is displayed, the user is prompted for additional information particular to that block 


selected. The dialog box also contains a complete explanation of all connections to that 








particular block and what the block itself is capable of accomplishing. This information 
can range from maximum queue length to message data sizes depending on the block 
chosen. 

2. Hierarchy 

Although, the model appears at first to be fairly simple, Extend™ allows for 
blocks to be "buried" beneath other blocks. Extend™ allows the user to select blocks and 
provides the option for them to be made "hierarchical". This in turn gathers all of the 
chosen blocks and places one hierarchical block in their place. All of the connections 
previously used are still intact with System chosen names as illustrated in the model 
description chapter. Although all of the blocks are accessed and used in sequence, this 
optional use of hierarchy is especially useful when there are too many connections or too 
many blocks for the user to view everything clearly. This option can also be chosen 
many times once sub-blocks are defined. Therefore many layers can be contained within 
each model. The model developed for this thesis has four layers. 
B. BLOCK DESCRIPTION 


1. FNMOC Monterey 


The hierarchical block containing the FRMOC logo represents this portion of the 
model. As Figure 2 illustrates, it has four connections available for traffic flow into the 


Ethernet block for eventual traffic to the NLMOC Norfolk block. 
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Figure 2. Top Model Layer 


Although it is possible for messages to flow from Monterey back into Monterey 
using this model, there is no traffic directed in this fashion. In the upper left-hand commer 
of Figure 2, there is also a clock icon indicating to Extend™ that this will be a discrete 


event model. 
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a. NOGAPS 
By double clicking on the FNMOC Monterey block, the layer beneath the 


block is revealed. Figure 3 illustrates this next layer. 






Con40ut ConsOut 





: Alla atic 


DN SR OR “cam sibteolehanerared 


NOGAPS 


For Future Use 


[Con7in ; 
Figure 3. FNMOC Monterey Block (Inputs and Outputs) 


The block represented by the Tropical Atlantic Naval Operational Global 
Atmospheric Prediction System (NOGAPS) logo indicates the portion of the model 
where the large data transfer is originated. This data is sent every twelve hours to 
NLMOC Norfolk. 

b. Web Server 

The web server block immediately adjacent to the NOGAPS block, both 
receives requests for data and sends updated data from FNMOC Monterey every fifteen 
minutes via the Ethernet connection. All messages are destined for NLMOC Norfolk via 
the Ethernet block. The typical message sizes are 250 kilobytes received and 100 
kilobytes sent. This message traffic mimics the actual data sizes for messages that 
request forecast weather updates and the update itself respectively. This data is also 


allowed to vary in time by using a standard normal distribution with a mean of sending a 
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message every 15 minutes and a standard deviation of five seconds. This more 
realistically simulates unforeseen line delays. 

c. For Future Use 

Both blocks in Figure 3 that read "For Future Use" are intended for 
potential studies to be accomplished beyond the scope of this thesis. However, each will 


generate and receive message traffic as directed by the user just as the other blocks. 





G te M an 
enerate Msgs Source Msg Que Msg Biocking 


Figure 4. FNMOC Monterey Block (Message Generation) 


(1) Message Generation with Attributes. The first block in 
Figure 4 actually generates messages for the simulation. It is here that the user defines 
the timing of cach message. In this case the large data message is sent once every twelve 
hours. However. itis also allowed to be sent early or late within a five second standard 
normal distnbution with a mean of twelve hours. 

The next block receives the item and appends user-defined 


attnbutes onto it. This block is also hierarchical and is illustrated in Figure 5. 
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Figure 5. FNMOC Monterey Block (Message Attributes) 


It is finally within this layer that the message receives all of its 
attnbutes such as destination, message size, and message identification. The first block 
in Figure 5 is the system assigned connection for the generated message that is input from 
the previous layer. The next block provides the message with a randomly chosen 
message identification. Once set, the message identification is requested using the block 
marked "Get A" for "get attribute". This identification is used to select a row of data in 
the "file" block. That row of data contains the message's destination and size in bytes. 
Each message now contains its own discrete data and is stamped with a system time. The 
system time will support the measurement of time delay for the Ethernet. 

Referring once again to Figure 4, the message with all of its 
attributes is sent into a first-in-first-out (FIFO) queue as required by Extend™ for the 
purpose of model integrity. This is done to ensure that no messages are lost in transition. 


The messages are then sent to the packet building block. 
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(2) Packet Building Block. In this block each message is 


simply parsed into the correct number of packets for the Ethernet. 
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Figure 6. FNMOC Monterey Block (Build Packets: First Half) 


As illustrated in Figure 6, the block again first starts wath the 
hierarchical connection set by the system. The message then goes into a service activity 
block, which serves as a conditional wait. This ensures that it is the only message being 
serviced at the present time. The logical block beneath it provides the logical input of 
"full" if the final FIFO queue of this block is not empty. 

Next the message is asked for its size. That size is divided by 1500 
which is the standard Ethernet packet size. This renders the number of packets required 
by this message. The message is now sent into another FIFO queue after which the 


number of packets is requested from it. Figure 7 illustrates what happens next. 
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Figure 7. FNMOC Monterey Block (Build Packets: Second Half) 


In Figure 7 the message is then selected according to its size. Only 
a message smaller than 1500 bytes is allowed to travel along the "A" pathway where it 
will be stamped "Last Packet", all other inbound messages are sent along the "B" 
pathway. Last packet will later be used as output to count the number of messages 
processed through the system. Next they arrive at second block above marked with an "a, 
b or c” output. This "unbatch" block takes the inbound message and duplicates it, 
sending one copy to be stamped "last packet" and one copy to take on the value of the 
number of packets it requires. These items are all rejoined and sent to the final FIFO 
queuc where the number of packets are sent followed by the last packet. Once the queue 
is empty the logical variable "full" is reset to zero allowing the next message to be 
processed. 

From here the packets are all sent via the outbound connection to 


the Ethernet block for further processing. 
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2. Ethernet 


This portion of the model is represented by a user defined Ethernet block. As 
Figure 8 shows, eight connections are available, this model uses five of them. Four of the 


connections are from NLMOC Monterey and one leads to NLMOC Norfolk. 
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Figure 8. Ethernet Block (First Half) 


As Figure 8 illustrates, all of the nodes have an inbound connection. As packets 
arrive they are immediately sent into a hierarchical block where bandwidth is verified and 
therefore time delay is determined. Afterwards, each packet is asked if it is the "last 
packet". If it is the "last packet" then it is sent along the path marked "b" and one 
message 1s counted. All packets, including the "last packet" are then gathered and sent to 


the second half of this block as if Figure 9. 
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Figure 9. Ethemet Block (Second Half) 


As Figure 9 illustrates the inbound packets are al] gathered and copies are sent 


into another FIFO queue where their destination is queried and into an output to count all 





processed packets. Packets are then sent onward to their proper and final destination. 
a. Ethernet Bit Rate Delay 
Figure 8 shows this hierarchical block, which is further illustrated in 


Figure 10 below. 
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Figure 10. Ethernet Block (Bit Rate Delay) 
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As Figure 10 begins, packets are brought in via the system connection and 
put into a “last-in-first-out" (LIFO) queue. This allows for simple packet collision 
modeling by allowing the last packet to simply go first. Therefore, in the event that two 
or more packets should be competing for Ethernet processing, the last one entering will 
be serviced first. This "back-off" of packet processing simulates in a simple manner the 


transfer protocol used for Ethernet processing. 


This model realistically will have no collisions because of the small 
amount of message traffic and because the line used between FNMOC Monterey and 
NLMOC Norfolk is a dedicated line without any requests or messages originating from 
other customers. However, if more customers were added in the future, a more robust 


collision algorithm would have to be written for this model. 


Next each packet is asked for its size which is generally 1500 bytes unless 
itis the last packet when it may be less. The correct time delay is determined by dividing 
the size of the packet by | the bandwidth available. The percent of utilization of the 
Ethermet is then output and the packet is sent to complete the Ethernet block. 


3. NLMOC Norfolk 


This block is represented by the NLMOC Norfolk logo. It has one, two-way 
connection available from the Ethernet block available for traffic flow. It also contains 
the same hierarchical blocks for sending and receiving messages. However the data it 
sends corresponds to 250 kilobyte size request messages. These messages like their 


corresponding replies from FNMOC Monterey, are allowed to vary according to a 
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standard normal distribution with a mean of fifteen minutes and a standard deviation of 


five seconds. 


a. Packet Reception 


As illustrated in Figure 11, packets arrive at their destination having 


completed the generation and Ethernet processing. 
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Figure 11. NLMOC Norfolk Block (Packet Reception) 


Packets are then sent into a FIFO queue for model integrity and sent 


immediately to the unpacking block. Figure 12 illustrates how packets are unpacked. 





Figure 12. NLMOC Norfolk Block (Packets Unpacked) 
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Packets are first queried if it is the last packet. If the packet is the last 


packet then it is selected to follow along the "b" path and a complete message is counted. 





Otherwise the packet exits along the "a" path and it is counted as a single packet. 


4. Output 


The output block gathers and displays the chosen data from each model run. As 
Figure 13 illustrates, this block reads the Ethernet utilization, as well as messages and 


packets processed by the network. 
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Figure 13. Output Block 


The first block labeled with an "R" takes as its input the Ethernet utilization. This 
is sampled every half second, as directed by the "Sample Rate" block. Additionally all 
counters and activities are cleared once a new input is received. This ensures that no 


aggregation of data occurs. Three plotter blocks are then given these outputs to plot. 
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IV. MODEL RESULTS 


A. OVERVIEW 

The model was run on a desktop, Pentium DI™, 500-megahertz computer. Each 
complete run required approximately 20 minutes to complete. Each run is executed for 
5200 seconds. This provides enough time for each contributing node to complete its 
transmission and eventual reception of data. Originally longer run times were explored; 
however, the model’s behavior remained the same whether it was run for 14.4 hours or 26 
hours. The only difference was that the graphic output became more difficult to read. 

Additionally, the model iia run for three different excursions. Each excursion 
below, detailed on Table 1, is motivated by highly probable upcoming proposals with 


regard to system improvements. 


Bandwidth 


1.544 Mbps (T-1) 
wl _ 


1.544 Mbps (T-1) 









Message Traffic 
NLMOC Requests updates every 15 min. (050KB) 
FNMOC Sends update every 15 min. (100KB) 

FNMOC Sends 1 GB every 12 hours. 
NLMOC Requests updates every 15 min. (250KB) 
FNMOC Sends update every 15 min. (LOOKB) 

FNMOC Sends 1 GB every 12 hours. 
NLMOC Requests updates every 15 min. (250KB) 
FNMOC Sends update every 15 min. (1OOKB) 

FNMOC Sends 83.3 MB every hour. 





















Table 1. Excursion Data 


B. EXCURSION ONE (T-1 LINE) 


For the first excursion the available bandwidth used is 1.544 megabits per second ~ 
over the Ethernet. This is the standard T-1 bandwidth. As Figure 14 indicates, the 


Ethernet runs smoothly, with 100 percent utilization occurring only every 16 minutes 
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approximately and lasts for less than one second. This occurs until the very large, one 
gigabyte data transfer commences. When this occurs, all other Ethernet traffic is delayed 
approximately one hour and twenty-eight minutes as shown in the heavily shaded region 


in Figure 14 below. 


Utilization Pa 
Ethernet Utilization (% 
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Figure 14. 1 GB Message Sent Every 12 Hours via T-1 Line (1.544 Mbps) 


C. EXCURSION TWO (10 MEGABITS PER SECOND) 


For the second excursion the available bandwidth used is improved to 10 
megabits per second over the Ethernet. This was done because FNMOC Monterey is 
able to transfer data at 10 megabits per second even though NLMOC Norfolk can only 
receive data at the standard T-1 bandwidth. However by expanding the service level 
agreement NLMOC Norfolk’s receive rate could be improved. As expected, Figure 15 
illustrates that the Ethernet runs even more smoothly than before, with typical maximum 
Ethernet utilization remaining at 20 percent. This occurs approximately every 16 


minutes. Additionally, when the very large, one gigabyte data transfer occurs, the 
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Ethernet is delayed approximately 3 minutes - a decrease of one hour and twenty-five 
minutes. 


Utilization 
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Figure 15. 1 GB Message Sent Every 12 Hours via 10 Mbps Line 


D. EXCURSION THREE (T-1 LINE: HOURLY OUTPUT) 


The third excursion uses an available bandwidth of 1.544 megabits per second, 
the same as the first excursion. However in this scenario, the large, one gigabyte file is 
parsed into twelve equal parts of 83.3 megabytes instead of being sent all at one time. 
Each purt is then transmitted every hour. This could be accomplished through a change 
in the management of the outbound database. As Figure 16 indicates the Ethernet runs 
fairly smoothly, with 100 percent utilization occurring every fifteen minutes as well as 
every hour when the 83.3 megabyte file is sent. However the Ethernet delay is now just 


7.2 minutes every hour as a result in the change of data management. 
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Figure 16. 83.3 MB Message Sent Every Hour via T-1 Line 
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Vv. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

Although data is routinely sent via a dedicated leased line from FNMOC 
Monterey to NLMOC Norfolk, the time delay experienced by sending a one gigabyte 
message once every twelve hours is one hour and twenty-eight minutes. This delay 
causes all other traffic to wait until this message completes its transmission. If the line 
bandwidth were improved, or if the size of the message were decreased by allowing parts 
of it to be sent incrementally, this line delay would either be decreased or at least occur 
for much jisiies periods of time and less often. 

1. NLMOC Norfolk 

NLMOC is a major recipient of weather data. The files that it receives are then 
added to other observations in order to service its customer as well. However, as is 
typical among users of data of all types, NLMOC Norfolk routinely requests all the data 
that can be sent. Although they could request fewer files they currently request as much 
data as is available. This is done to achieve the most up to date forecasts in support of 
fleet operations and seems reasonable with respect to urgent operations. Unfortunately, 
in terms of available bandwidth, this is not very economical. Although it is beyond the 
scope of this thesis, if there were some method of reducing the data requested this would 
also reduce the time delay. 


B. RECOMMENDATIONS 


The goal of this thesis is to allow the user the opportunity to simulate proposed 


system changes to the connection between FNMOC Monterey and NLMOC Norfolk. 


ZI 














Having completed three excursions with this model the first goal of simulating actual line 
delay was accomplished. Additionally, the second goal was to explore the effects of 
altering the system through changing the bandwidth. This alternative indicates an 
immense decrease in message time can truly be achieved, especially if bandwidth could 


be improved to 10 megabits per second. 


Finally, in allowing the current system to be altered to allow data to be sent every 
hour instead of once every twelve hours also shows a great decrease in system time delay. 
In choosing between these two, the second should likely be chosen because it also seems 


to be the least expensive of the excursions explored. 


Additionally, as the budget allows, greater bandwidth should be purchased to 
allow quicker transmission of the requested data. However this line bandwidth should 
not exceed 10 megabits per second because FNMOC Monterey is unable to send it any 


faster. 
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